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Abstract. Virtual integration techniques focus on building architectural 
models of systems that can be analyzed early in the design cycle to 
try to lower cost, reduce risk, and improve quality of complex embed¬ 
ded systems. Given appropriate architectural descriptions and composi¬ 
tional reasoning rules, these techniques can be used to prove important 
safety properties about the architecture prior to system construction. 
Such proofs build from “leaf-level” assume/guarantee component con¬ 
tracts through architectural layers towards top-level safety properties. 
The proofs are built upon the premise that each leaf-level component 
contract is realizable ; i.e., it is possible to construct a component such 
that for any input allowed by the contract assumptions, there is some 
output value that the component can produce that satisfies the contract 
guarantees. Without engineering support it is all too easy to write leaf- 
level components that can’t be realized. Realizability checking for propo¬ 
sitional contracts has been well-studied for many years, both for compo¬ 
nent synthesis and checking correctness of temporal logic requirements. 
However, checking realizability for contracts involving infinite theories 
is still an open problem. In this paper, we describe a new approach for 
checking realizability of contracts involving theories and demonstrate its 
usefulness on several examples. 


1 Introduction 

In the recent years, virtual integration approaches have been proposed as a means 
to lower cost and improve quality of complex embedded systems. These ap¬ 
proaches focus on building architectural models of systems that can be analyzed 
prior to construction of component implementations. The objective is to dis¬ 
cover and resolve problems early during the design and implementation phases 
when cost impact is lower. Several architecture description languages such as 
AADL Q], SysML [2], and AUTOSAR [3] are designed to support such an engi¬ 
neering process, and there has been significant effort to analytically determine 


system performance @0, fault tolerance 0, security |BJ, and safety [7 using 
these techniques. 

In an ongoing effort at Rockwell Collins and The University of Minnesota, we 
have been pursuing virtual integration using compositional proofs of correctness. 
The idea is to support hierarchical design and analysis of complex system archi¬ 
tectures and co-evolution of requirements and architectures at multiple levels of 
abstraction [8j . This was based on two observations about software development 
for commercial aircraft: first, that component-level errors are relatively rare and 
that most problems occur during integration 0, and second, that requirements 
specifications often contain significant numbers of omissions or errors m that 
are at the root of many of the integration problems. Specifically, the problem 
involves demonstrating satisfaction arguments HD, i-e-, that the requirements 
allocated to components and the architecture connecting those components is 
sufficient to guarantee the system requirements. We have created the AGREE 
reasoning framework m to support compositional assume/guarantee contract 
reasoning over system architectural models written in AADL. 

Such proof systems build from “leaf-level” assume/guarantee component con¬ 
tracts through architectural layers towards proofs of top-level safety properties. 
The soundness of the argument is built upon the premise that each leaf-level 
component contract is realizable; i.e., it is possible to construct a component 
such that for any input allowed by the contract assumptions, there is some out¬ 
put value that the component can produce that satisfies the contract guarantees. 

Unfortunately, without engineering support it is all too easy to write leaf-level 
components that can’t be realized. When applying our tools in both industrial 
and classroom settings, this issue has led to incorrect compositional “proofs” 
of systems; in fact the goal of producing a compositional proof can lead to en¬ 
gineers modifying component-level requirements such that they are no longer 
possible to implement. In order to make our virtual integration approach rea¬ 
sonable for practicing engineers, tool support must be provided to check whether 
components are realizable. 

Realizability checking for propositional contracts has been well-studied for 
many years (e.g., |13 | 14|15 | 16j ), both for component synthesis and checking cor¬ 
rectness of temporal logic requirements. Checking realizability for contracts in¬ 
volving theories, on the other hand, is still an open problem. In this paper, we 
describe a new approach for checking realizability of contracts involving theories 
and demonstrate its usefulness on several examples. Our approach is similar to 
k-induction over quantified formulas. We describe two algorithms. The first is 
sound for both proofs and counterexamples, but computationally intractable. 
The second algorithm is not sound for counterexamples (i.e., it may return a 
‘false counterexample’ to a problem that is in fact realizable), but we have found 
it fast and accurate in practice. 

The rest of the paper is structured as follows. In Section[2]we will describe our 
motivation and an example to illustrate realizability, and will define realizability 
formally in Section [3] We next describe two algorithms for checking realizability 
in Section 01 our implementation in the AGREE tool suite in Section [5j and our 




experience using the realizability check in Section [G] Section [7] describes related 
work and Section [5] concludes. 

2 Motivation and Example 

We have been pursuing a proof-based virtual integration approach for building 
complex systems using the architecture description language AADL pQ and the 
AGREE compositional reasoning system |T2j. We have demonstrated the effec¬ 
tiveness of the approach on a variety of industrial-scale systems, including the 
software controller for a patient-controlled analgesia (PCA) infusion pump [IT] , 
a dual flight-guidance system (T2] , and several more recent models, such as a 
quad-redundant flight control system and a quadcopter control system. We are 
using this approach on the DARPA HACMS program to build secure vehicles 
and to demonstrate how to apply virtual integration on industrial scale systems 
to facilitate technology transfer. 

As part of the HACMS project, we attempted a feasibility test via a class¬ 
room exercise. We used the AADL and AGREE tools in a class assignment in a 
graduate-level software architecture class. The students were organized into six 
teams of four students. Each team was asked to specify the control software for 
a simplified microwave oven in AADL using a virtual integration approach. The 
software was split into two subsystems: one for controlling the heating element 
and another for controlling the display panel, with several requirements for each 
subsystem. The goal was to formalize these component-level requirements and 
use them to prove three system-level safety requirements. 

The results of the initial experiment were sobering. All student groups were 
able to prove the system-level requirements starting from formalizations of the 
component requirements. Unfortunately, in many cases, the proofs succeeded be¬ 
cause the components were incorrectly specified. In fact, only one of the teams 
had written component-level requirements that could be implemented. The other 
teams had requirements which were inconsistent under certain input conditions. 
For example, one team produced the following informal component-level require¬ 
ments: 

[ Microwave-1 - While the microwave is in cooking mode, seconds_to_cook 
l shall decrease. 

[ Microwave-2 - If the display is quiescent (no buttons pressed) and the 
I keypad is enabled, the seconds_to_cook shall not change. 

and then produced the following formalized requirement^: 

guarantee: is_cooking' => seconds_to_cook , < seconds_to_cook — 1 

guarantee: (->any_digit_pressed A keypad_enabled) =>■ 
secondsTo.cook' = seconds_to_cook 

3 We have translated this property and others from the higher level AGREE syntax 
into a two-state form that is used throughout this paper. 







These formalized guarantees fail to avoid the conflict in the seconds_to_cook vari¬ 
able between the IMicrowavc-ll and IMicrowave-21 requirements, as they cannot 
be both satisfied in a case where the microwave is cooking and the keypad is 
enabled. This error was not caught despite an analysis built into an early version 
of AGREE that checks contracts for consistency , i.e., whether the conjunction of 
a system’s guarantees is satisfiable. We realized that consistency checking does 
not actually provide a trustworthy answer because it only checks whether the 
system works in some external environment, not in all environments. Realiz¬ 
ability checking determines whether or not the component works in all input 
environments that satisfy the component assumptions. 

From this experience, we decided that realizability checking was necessary for 
successful tech transfer of a virtual integration approach. The analysis was not 
only necessary for classroom settings. We also found problems with component- 
level requirements in two of our large-scale analysis efforts. Further, existing 
approaches for checking realizability do not allow predicates over infinite theories 
such as integers and reals, which are native to our AGREE contracts. 

In the following sections, we formally define realizability over transition sys¬ 
tems, as well as algorithms for checking realizability over infinite-state systems 
that are efficient and accurate in practice. A machine-checked formalization of 
the definitions and proofs in Coq can be found in a companion paper [18| . 

3 Realizability 

We assume the types state and input for states and inputs. We use s for variables 
of type state and i for variables of type input. State represents both internal state 
and external outputs. A transition system is a pair (/, T ) where / : state — > bool 
holds on the initial states states and T : state x input x state —> bool holds on 
T(s,i,s') when the system can transition from state s to state s' on receipt of 
input i. We assume the usual notion of path with respect to a transition relation. 

A contract specifies the desired behavior of a transition system. A con¬ 
tract is a pair (A, G) of an assumption and a guarantee. The assumption A : 
state x input —>• bool specifies for a given system state which inputs are valid. 
The guarantee G is a pair (G/,Gt) of an initial guarantee and a transitional 
guarantee. The initial guarantee G/ : state —» bool specifies which states the sys¬ 
tem may start in, that is, the possible initial internal state and external outputs. 
The transitional guarantee Gt '■ state x input x state —> bool specifies for a given 
state and input what states the system may transition to. 

We now define what it means for a transition system to realize a contract. 
This requires that the system respects the guarantee for inputs which satisfying 
the contract. Moreover, the system must always remain responsive with respect 
to inputs that satisfying the assumptions. In order to make this definition precise, 
we first need to define which system states are reachable given some assumptions 
on the system inputs. 

Definition 1 (Reachable with respect to assumptions). Let (I,T) be a 
transition system and let A : state x input — > bool be an assumption. A state of 
(I, T) is reachable with respect to A if there exists a path starting in an initial 






state and eventually reaching s such that all transitions satisfying the assump¬ 
tions. Formally, Reachable^ (s) is defined inductively by 

Reachable^s) = /(s) V 3s prev , i. Reachable J 4 (s prev ) A A(s prev , i) A T(s prev , i, s ) 

Definition 2 (Realization). A transition system (I,T) is a realization of the 
contract ( A , ( Gj,Gt )) when the following conditions hold 

1. Vs. I(s) => G/(s) 

2. \/s,i,s'. Reachable^s) A A{s, i) A T(s, i, s') => Gt(s, i, s') 

3. 3s. I{s) 

4- Vs, A Reachable,* (s) A A(s, i) 3s'. T(s, i, s') 

The first two conditions in Definition [2] ensure that the transition system 
respects the guarantees. The second two conditions ensure that the system is 
non-trivial and responsive to all valid inputs. 

Definition 3 (Realizable). A contract is realizable if there exists a transition 
system which is a realization of the contract. 

Definitions [5] and [3] are useful for directly defining realizability, but not very 
useful for checking realizability. We now develop an equivalent notion which is 
more suggestive and amenable to checking. This is based on a notion called 
viability. Intuitively, a state is viable with respect to a contract if being in that 
state does not doom a realization to failure. We can capture this notion without 
reference to any specific realization, because condition 2 in the definition of 
realization tells us that Gt is an over-approximation of any T. 

Definition 4 (Viable). A state s is viable with respect to a contract (A, ( G/, Gt)), 
written Viable(s), if Gt can keep responding to valid inputs forever, starting from 
s. Informally, one can say that a state s is viable if it satisfies the infinite for¬ 
mula: 

Vi i. A(s, i\) => 3si. Gt(s, *i, si) A V* 2 - A(si, if) => 3 s 2 . Gt(si, ii, S 2 ) A Vi 3 . • • • 

Formally, viability is defined coinductively by the following equation 

Viable(s) = Vi. A(s, i) => 3s'. Gt(s, i, s') A Viable(s') 

Theorem 1 (Alternative realizability). A contract (A, (G/,Gt)) is realiz¬ 
able if and only if 3s. Gi(s) A Viable(s). 

Proof. For the “only if” direction the key lemma is Vs. Reachable,*^) =>• Viable(s). 
This lemma is proved by coinduction and follows directly from conditions 2 
and 4 of Definition [21 Then by conditions 1 and 3 we have some state s such 
that I(s) and G/(s). Thus Reachable^s) holds and applying the lemma we get 
G/(s) A Viable(s). 

For the “if” direction, let so be such that G/(so) and Viable(so). Define 
I(s) = (s = so) and T(s,i,s r ) = Gr(s,*,s') A Viable(s'). Conditions 1, 2, and 
3 of Definition [2] are clearly satisfied. Condition 4 follows from the observation 
that Vs. ReachableA(s) =>■ Viable(s) and from the definition of viability. 


4 An Algorithm for Checking Realizability 

In this section we develop two versions of an algorithm for automatically checking 
the realizability of a contract. The first version is based on Theorem Q] together 
with under- and over-approximations of viability. An over-approximation is use¬ 
ful to show that a contract is not viable, while an under-approximation is useful 
to show that a contract is viable. The second version of the algorithm follows 
from the mitigating the intractability of the first version. 

We first define an over-approximation of viability called finite viability based 
on a finite unrolling of the definition of viability. Because this is an over-approximation, 
if a contract does not have an initial state which is finitely viable, then the con¬ 
tract is not viable. We formalize this when we prove the correctness of the 
realizability algorithm. 

Definition 5 (Finite viability). A state s is viable for n steps, written Viable„(s) 
if Gt can keep responding to valid inputs for at least n steps. That is, 

Mil. A(s, ii) =>■ 3 si. Gt(s, ii, si) A 

Vi 2 . A(si, *2) =$■ 3 s 2 . Gt(s 1, *2, s 2 ) A • • • A 

VZn- A(Sn — l,in) 3Sn- Gt (,Sn— 1 , in > S>n) 


All states are viable for 0 steps. 

We next define an under-approximation of viability based on one-step exten¬ 
sion. This notion looks if Gt can respond to valid inputs given a finite historical 
trace of valid inputs and states. 

Definition 6 (One-step extension). A state s is extendable after n steps, 
written Extend„(s), if any valid path of length n from s can be extended in re¬ 
sponse to any input. That is, 

Vii, Sij,.., i n , s n . 

A(s, i\) A Gt(s, ii, si) A ■ • • A A(s„_i, i„) A Grisn-ifin, s n ) => 

Vi. A(s n ,z'j == r* 3s . G f, j i (s ri , z, s ) 

We now use these two notions to formally define our realizability algorithm. 
The core of the algorithm is based on two checks called the base and extend 
check. 

Definition 7 (Realizability Algorithm). Define the checks: 

BaseCheck(n) = 3s. G/(s) A Viable„(s) 

ExtendCheck(n) = Vs. Extend„(s) 

The following algorithm checks for realizability or unrealizability of a contract. 


for n = 0 to oo do 

if not BaseCheck(n) then 
return “unrealizable” 
else if ExtendCheck(n) then 
return “realizable” 
end if 
end for 

Theorem 2 (Soundness of “unrealizable” result). If 3n. -iBaseCheck(n) 

then the contract is not realizable. 

Proof. First we show Vs, n. Viable(s) => Viable„(s) by induction on n. The result 
then follows from Theorem [1] 

Theorem 3 (Soundness of “realizable” result). If 3 n. BaseCheck(?i) A 
ExtendCheck(n) then contract is realizable. 

Proof. First we show how Extend„(s) can be used to shift Viable n (s) forward. 
The following is proved by induction on n. 

Vs, n, i. Extend„(s) A Viable„(s) A A(s, i) => 3s'. Gt(s, i, s') A Viable„(s') 

Using this lemma we can show the following by coinduction. 

Vs, n. Viable„(s) A ExtendCheck(n) => Viable(s) 

The result then follows from Theorem [I] 

Corollary 1 (Soundness of Realizability Algorithm). The Realizability 
Algorithm is sound. 

Due to the approximations used to define the base and extends check, the 
algorithm is incomplete. The following two examples show how both realizable 
and unrealizable contracts may send the algorithm into an infinite loop. 

Example 1 (Incompleteness of “realizable” result). Suppose the type state is in¬ 
tegers. Consider the contract: 

A(s, i) = T G/(s) = T G T {s,i,s') = (s ^ 0) 

This contract is realizable by, for example, a system that starts in state 1 and 
always transitions into the same state. Yet, for all n, Extend Check(n) fails since 
one can take a path of length n which ends at state 0. This path cannot be 
extended. 

Example 2 (Incompleteness of “unrealizable” result). Suppose the type state is 
integers. Consider the contract: 

A(s, i) = T Gi{s) = (s > 0) Gt(s, i, s') = (s' = s — 1 A s' > 0) 

This contract is not realizable since in any realization the state 0 would be 
reachable, but the contract does not allow a transition from state 0. However, 
BaseCheck(n) holds for all n by starting in state s = n. 


Implementing this algorithm requires a way of automatically checking the 
formulas BaseCheck(?z) and ExtendCheck(n) for validity. This can be done in 
an SMT-solver that supports quantifiers over the language the contract is ex¬ 
pressed in. Checking ExtendCheck(n) is rather nice in this setting since it has 
only a single quantifier alternation. Moreover, using an incremental SMT-solver 
one can reuse much of the work done to check ExtendCheck(n) to also check 
ExtendCheck(n + 1). However, BaseCheck(n) is problematic. First, it has 2 n 
quantifier alternations which puts even small cases outside the reach of mod¬ 
ern SMT-solvers. Second, the quantifiers make it impractical to reuse the results 
of BaseCheck(n) in checking BaseCheck(n + 1). Finally, due to the quantifiers, 
a counterexample to BaseCheck(n) would be difficult to relay back to the user. 
Thus we need a simplification of BaseCheck(n) in order to make our algorithm 
practical. 

Definition 8 (Simplified base check). Define a simplified base check which 
checks that any path of length n from an initial state can be extended one step. 

BaseCheck^n) = Vs. G/(s) =>- Extend n (s) 

First, note that this check has a single quantifier alternation. Second, this 
check can leverage the incremental features in an SMT-solver to use the results 
of BaseCheck^n) in checking BaseCheck^n + 1). Finally, when this check fails it 
can return a counterexample which is a trace of a system realizing the contract 
for n steps, but then becoming stuck. This provides very concrete and useful 
feedback to system developers. The correctness of this check is captured by the 
following theorem. 

Theorem 4 (One-way soundness of simplified base check). 

(3s. G/(s)) Vn. (Vfc < n. BaseCheck^fc)) =>■ BaseCheck(n) 

Proof. We first prove the following by induction on n: 

Vs,n. Extend„(s) A Viable„(s) =>■ Viable n+ i(s) 

The final result follows using this and induction on n. 

Thus replacing BaseCheck(n) in the realizability algorithm with BaseCheck^n) 
preserves soundness of the “realizability” result. However, because the implica¬ 
tion in Theorem [H is only in one direction, the algorithm is no longer sound for 
the “unrealizable” result. That is, it may return a counterexample showing n 
steps of a realization of the contract that gets into a stuck state. The following 
example makes this point explicit. 

Example 3. Consider again Example |T] where the type state is integers and the 
contract is: 

A(s,i) = T G/(s)=T G t (s,m') = (s^0) 

As before, this contract is easily realizable. However. BaseCheck , (?r) fails for all 
n since it will consider a path starting at state n and transitioning n steps to 
state 0 where no more transitions are possible. 


The benefits of this second version of the algorithm outweigh its costs. The 
cases where a contract is realizable, yet fails the modified base check seems 
unlikely in practice. We have encountered none in our case studies. Moreover, 
when a contract does spuriously fail the simplified base check, it can almost 
always be rewritten into a form which would pass. 

5 Implementation 

We have built an implementation of the realizability algorithm as an extension 
to JKind m, a re-implementation of the KIND model checker [20] in Java. Our 
tool is called JRealizability and is packaged with the latest release of JKind. The 
model’s behavior is described in the Lustre language, which is the native input 
language of JKind and is used as an intermediate language for the AGREE tool 
suite. 

We unroll the transition relation defined by the Lustre model into SMT 
problems (one for the base check and another for the extend check) which can 
be solved in parallel. We use the SMT-LIB Version 2 format which most mod¬ 
ern SMT solvers support. The most significant issue for SMT solvers involves 
quantifier support, so we use the Z3 SMT solver m which has good support 
for reasoning over quantifiers and incremental search. The tool is often able to 
provide an answer for models containing integer and real-valued variables very 
quickly (in less than a second). Because of the use of quantifiers over a range of 
theories, it is possible that for one of the checks, Z3 returns unknown; in this 
case, we discontinue analysis. In addition, because our realizability check is in¬ 
complete, the tool terminates analysis when either a timeout or a user-specified 
max unrolling depth (default: 200) is reached. In this case we are able to re¬ 
port how far the base check reached which may provide some confidence in the 
realizability of the system. 

6 Case Studies 

As a part of testing the algorithm in actual components, we examined three 
different cases: a quad-redundant flight control system, a medical infusion pump, 
and a simple microwave controller. In this section, we provide a brief description 
of each case study and summarize the results in Tabled] at the end of the section. 

6.1 Quad-Redundant Flight Control System 

We ran our realizability analysis on a Quad-Redundant Flight Control System 
(QFCS) for NASA’s Transport Class Model (TCM) aircraft simulation. We were 
provided with a set of English language requirements for the QFCS components 
and a description of the architecture. We modeled the architecture in AADL and 
the component requirements as assume/guarantee contracts in AGREE. As the 
name suggests, the QFCS consists of four redundant Flight Control Comput¬ 
ers (FCCs). Each FCC contains components for handling faults and computing 
actuator signal values. One of these components is the Output Signal Analysis 
and Selection component (OSAS). The OSAS component is responsible for de¬ 
termining the output gain for signals coming from the control laws and going 


to the actuators. The output signal gain is determined based on the number of 
other faulty FCCs or based on failures within the FCC containing the OSAS 
component. The OSAS component contains 17 English language requirements 
including the following: 


OSAS-S-170 - If the local Cross Channel Data Link (CCDL) has failed, 
OSAS shall set the local actuator command gain to 1 (one). 


J 


C OSAS-S-240 - If OSAS has been declared failed by CCDL, OSAS shall 

I set the actuator command gain to 0 (zero). 

We formalized these requirements using the following guarantees: 


guarantee: ccdLfailed => (fcc.gain' = 1) 
guarantee: osas_failed => (fcc_gain / = 0) 


These guarantees are contradictory in the case when the local CCDL has failed 
and the local CCDL reports to the OSAS that the OSAS has failed. This error 
eluded the engineers who originally drafted the requirements as well as the en¬ 
gineers who formalized them. In this case, there should be an assumption that 
if the CCDL has failed then it will not report to the OSAS that the OSAS has 
failed. This was not part of the original requirements. However, AGREE’s real¬ 
izability analysis was able to identify the error and provide a counterexample. 


6.2 Medical Device Example 

Our realizability tool was also used to verify the realizability of the components 
in the Generic Patient Controlled Analgesia infusion pump system that was 
described in |22j . The controller consists of six subcomponents that were given 
as input for the tool to verify the requirements described inside. While five of the 
models were proven to be realizable, a subtly incorrect requirement definition 
was found in the contract for the controller’s infusion manager. 

^ GPCA-1 - The mode range of the controller shall be one of nine different ^ 

modes. If the controller is in one of the first two modes the commanded flow 
^ rate shall be zero. 

guarantee: 

(IM_OUT.Current_System_Mode' > 0) A 
(IM_OUT.Current_System_Mode' < 8) A 
(IM.OUT.Current.System.Mode' = 0 => 

IM_OUT.Commanded_Flow_Rate , = 0) A 
(IM_OUT.Current_System_Mode' = 1 => 
IM_OUT.Commanded_Flow_Rate , = 0) 


(1) 












GPCA-2 - Whenever the alarm subsystem has detected a high severity 
hazard, then Infusion Manager shall never infuse drug at a rate more than 
the specified Keep Vein Open rate. 

guarantee: 

(TLM_M0DEJN.System.0n' A 

ALARM JN.Highest.LeveLAIarm' = 3) =>• 
(IM_OUT.Commanded_Flow_Rate / = CONFIG_IN.Flow_Rate.KVO') 


( 2 ) 


The erroneously defined guarantee © tries to assert that 
the IM_OUT.Commanded_Flow_Rate to some (potentially non-zero) 
Flow.Rate.KVO if the alarm input is 3; however, this may occur when 
the IM_OUT.Current_System_Mode is computed to be zero or one, in which case 
the flow rate is commanded to be 0. While discovering and fixing the problem 
was not difficult, the error was not discovered by the regular consistency check 
in AGREE. 

6.3 Microwave Assignment 

The realizability tool was used to check the contracts for the microwave models 
produced by the graduate student teams described in Section [2] that provided 
the initial motivation for this work. The microwave consists of two subsystems 
that manage the cooking element and display panel of the device. Table (T] shows 
the corresponding results for each team, named as MT1, MT2, etc. While every 
team but one managed to provide an implementable set of requirements for the 
microwave’s mode controller, there were several interesting cases involving the 
display control component. For space reasons, we highlight only one here. 

| Microwave-1 - While the microwave is in cooking mode, seconds.to.cook j 
1 shall decrease. j 


( Microwave-3 - When the keypad is initially enabled, if no digits are | 
l pressed, the value shall be zero. I 

Team 6 formalized these requirements as 

guarantee: (cooking.mode' = 2) =$■ (seconds.to.cook' = seconds.to.cook — 1) 
guarantee: (-ikeypad.enabled A keypad.enabled' A -^any.digit.pressed') =» 
(seconds.to.cook' = 0) 

In the counterexample provided, the state where the microwave is cooking 
(cooking.mode = 2) and no digit is pressed creates a conflict regarding which 
value is assigned to the seconds.to.cook variable: should it decrease by one, or 
be assigned to zero? This counterexample is interesting because it indicates a 
missing assumption on the environment: the keypad is not enabled when the 
cooking mode is 2 (cooking). Without this assumption about the inputs, the 
guarantees are not realizable. 








Case study 

Model 

Result 

Time elapsed (seconds) 

Base check depth 
(# of steps) 

QFCS 

FCS 

realizable 

1.762 

0 

QFCS 

FCC 

unrealizable 

0.981 

1 

GPCA 

Infusion Manager 

unrealizable 

0.2 

1 

GPCA 

Alarm 

realizable 

0.316 

0 

GPCA 

Config 

realizable 

0.102 

0 

GPCA 

OutputBus 

realizable 

0.201 

0 

GPCA 

System Status 

realizable 

0.203 

0 

GPCA 

Top .Level 

realizable 

0.103 

0 

MT 1 

Mode Control 

realizable 

0.229 

0 

MT 1 

Display Control 

unrealizable 

0.207 

1 

MT 2 

Mode Control 

realizable 

0.202 

0 

MT 2 

Display Control 

unknown 

1000 (tool timeout) 

1 

MT 3 

Mode Control 

realizable 

0.203 

0 

MT 3 

Display Control 

unrealizable 

0.202 

1 

MT 4 

Mode Control 

realizable 

0.202 

0 

MT 4 

Display Control 

unrealizable 

0.521 

1 

MT 5 

Mode Control 

unrealizable 

0.1 

1 

MT 5 

Display Control 

unrealizable 

0.222 

1 

MT 6 

Mode Control 

realizable 

0.201 

0 

MT 6 

Display Control 

unknown 

1000 (tool timeout) 

1 


Table 1 . Realizability checking results for case studies 

Tabled] contains the exact results that were obtained during the three case 
studies. Every “realizable” result was determined to be correct since an im¬ 
plementation was produced for each of the components analyzed, ensuring the 
accuracy of the tool. Every contract that was identified as “unrealizable” was 
manually confirmed to be unrealizable, i.e., there were no spurious results. Ad¬ 
ditionally, the number of steps that the base check required to provide a final 
answer was not more than one, with the unknown results being particularly in¬ 
teresting, as the tool timed out before the solver was able to provide a concrete 
answer. This shows that there is still work to be done in terms of the algorithm’s 
scalability, as well as an efficient way to eliminate quantifiers, making the solving 
process easier for Z3. 

7 Related Work 

The idea of realizability has been the subject of intensive study. Gunter et al. 
refer to it using the term relative consistency in 123] , while Pnuelli and Rosner 
use the term implementability in m to refer to the problem of synthesis for 
propositional LTL. Additionally, the authors in m proved that the lower-bound 
time complexity of the problem is doubly exponential, in the worst case. In the 
following years, several techniques were introduced to deal with the synthesis 
problem in a more efficient way for subsets of propositional LTL [ 24] , simple 
LTL formulas (El, ESI), as well as in a component-based approach |16] and 
specifications based on other temporal logics (ESI, El), such as SIS E3- Finally, 
an interesting and relevant work has been done regarding the solution to the 
controllability problem using in [28] [29] and [30], which involves the decision 



























on the existence a strategy that assigns certain values to a set of controllable 
activities, with respect to a set of uncontrollable ones. 

Recent work in solving infinite game problems I5II52I can be specialized to 
the problem of realizability. In this work, the authors describe a framework for 
analyzing arbitrary two-player games. To provide proofs within the framework, 
template formulas must be provided by the user that describe the shape of a 
Skolem function that is used to explicitly define an inductive invariant that 
demonstrates the realizability of a model. Although this work is more general 
than ours, the applicability of the approach requires user-provided templates 
that are problem specific, so is not entirely automated. 

The main contribution of our work is that it automatically checks the realiz¬ 
ability of infinite domain systems. The problem is, in general, undecidable. Still, 
the application of bounded model checking can still offer an approximate answer 
to the realizability problem as we experienced by the fact that Z3 managed to 
solve the majority of our test models. 

8 Conclusions and Future Work 

In this paper, we have presented a new approach for determining realizability 
of contracts involving infinite theories using SMT solvers. This approach allows 
analysis of a class of contracts that were previously not solvable using automated 
analysis. The approach is both incomplete and conservative, i.e., it may return 
“false positive” results, declaring that a contract is not realizable when it could 
be realized. However, it has been shown to be both fast and effective in practice 
on a variety of models. 

The results of this paper provide a good foundation towards further research 
in realizability. In much the same way that many properties are not inductive, 
some contracts cannot be proven realizable using one step extensions. We are ex¬ 
amining alternate algorithms, similar to approaches such as IC3 [551 . which sup¬ 
port property-directed invariant generation, to improve the approach presented 
here. However, this requires generalizing the IC3 approach to solve quantified 
formulas (as well as to generalize counterexamples over quantified formulas). 
We hope to demonstrate an approach involving a IC3-like algorithm in the near 
future. 

In addition, for realizable systems, it is likely that we want to consider the 
synthesis problem, which we have not explicitly considered in this paper. Syn¬ 
thesis aims to construct a concrete implementation of the contract, rather than 
determine its existence. It is known for propositional systems that the synthesis 
problem is equivalent in complexity to the realizability problem m , but it is 
not known (to us) whether this equivalence is true in the infinite-state case. 
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